perm filename FRM.MSG[P,JRA]2 blob
sn#430606 filedate 1979-04-07 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00056 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00007 00002 ∂21-NOV-75 2027 FTP: host MAXC
C00009 00003 ∂11-Aug-77 0447 RPG New MACLSP
C00013 00004 ∂02-Nov-77 1616 JP MACLSP meta-D directory feature
C00015 00005 ∂06-Nov-77 1503 RPG New features.
C00017 00006 ∂24-Nov-76 1518 RPG Debug/Step (SAIL)
C00018 00007 ∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
C00019 00008 ∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
C00020 00009 ∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
C00023 00010 ∂26-Feb-77 1624 RPG Eread
C00024 00011 ∂19-May-77 0118 JP running E from maclsp
C00025 00012 ∂01-Jul-77 2212 DCO MAIL in MACLSP
C00027 00013 ∂04-AUG-76 0908 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI) Hiya back
C00029 00014 ∂10-SEP-76 1253 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI)
C00030 00015 ∂03-Dec-76 2304 FTP:GLS at MIT-MC (Guy L. Steele, Jr. )
C00033 00016 ∂04-Dec-76 1321 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
C00035 00017 ∂27-Dec-76 1247 FTP: host AI xxx
C00036 00018 ∂06-Nov-77 1159 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) grumble, grumble
C00043 00019 ∂20-OCT-76 0944 RPG
C00045 00020 ∂25-OCT-76 1043 RPG
C00046 00021 ∂28-Oct-76 2107 RPG BOOK
C00053 00022 ∂10-Nov-76 1351 RPG PROGV Feature
C00055 00023 ∂11-Dec-78 1724 RPG NEWIO programming tips
C00057 00024 ∂21-Dec-78 1219 RPG Bug fix in NEWIO
C00059 00025 ∂09-Jan-79 1542 RPG MacLisp matcher
C00062 00026 ∂17-Jan-79 1546 RPG UTIL.>
C00063 00027 ∂22-DEC-75 0127 FTP:GLS at MIT-AI
C00064 00028 ∂23-DEC-75 1117 FTP:GLS at MIT-AI
C00065 00029 ∂30-DEC-75 0556 FTP:GLS at MIT-ML
C00066 00030 ∂01-JAN-76 0639 FTP:GLS at MIT-ML
C00067 00031 ∂19-JAN-76 1220 FTP:GLS at MIT-ML
C00069 00032 ∂12-FEB-76 0845 FTP:GLS at MIT-AI
C00073 00033 ∂03-Mar-77 1603 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) Knight displays
C00077 00034 ∂01-Feb-78 1057 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) last message
C00078 00035 ∂25-Jan-79 1821 GLS LISP etc.
C00080 00036 ∂27-Feb-78 1706 HPM more video
C00086 00037 ∂29-Oct-76 1101 RPG GRIND
C00088 00038 ∂14-Dec-76 2221 RPG Printing windows/SAIL
C00089 00039 ∂09-Jun-77 1415 RPG sewer OLDIO
C00091 00040 ∂23-FEB-76 1503 FTP: host HARV
C00094 00041 FORREST W. HOWARD JR.
C00095 00042 ∂09-MAR-76 1311 FTP:HOWARD at HARV-10 LISP/BOOK
C00098 00043
C00102 00044 ∂24-MAY-76 1141 FTP: host HARV
C00106 00045 ∂02-May-78 1245 MG ML (LCF metelanguage)
C00108 00046 ∂19-Jul-77 1436 JP
C00109 00047 ∂06-Apr-78 1232 RPG New Maclsp
C00115 00048 ∂05-Dec-78 0833 RG at MIT-AI (Richard Greenblatt)
C00116 00049 ∂21-Jan-79 2044 BAKER at MIT-AI (Henry G. Baker, Jr.) Lisp article
C00118 00050 ∂20-Jan-79 1445 Boyer at SRI-KL (Bob Boyer) Your book reviewed
C00120 00051 ∂20-Jan-79 1754 RZ at MIT-MC (Richard E. Zippel)
C00122 00052 ∂22-Jan-79 0637 RLB,RWK,RZ,HIC at MIT-MC BYTE paper on LIL
C00123 00053 ∂04-Feb-79 1226 RWK at MIT-MC (Robert W. Kerns)
C00128 00054 ∂21-Jan-79 0944 PHW at MIT-AI (Patrick H. Winston)
C00129 00055 ∂21-Jan-79 1528 BAK at MIT-MC (William A. Kornfeld) BYTE article
C00135 00056 ∂03-Feb-79 1116 BAK at MIT-MC (William A. Kornfeld)
C00136 ENDMK
C⊗;
∂21-NOV-75 2027 FTP: host MAXC
Date: 21 NOV 1975 2027-PST
From: MOORE at PARC-MAXC
Subject: LISP COMPILER
To: JRA at SU-AI
The files are <LISP>COMP and <LISP>LAP. You may use FTP
with name ANONYMOUS (password) anything. Let me know if
you have trouble.
J
-------
∂21-NOV-75 1000 FTP: host MAXC
Date: 21 NOV 1975 0959-PST
From: MOORE at PARC-MAXC
To: JRA at SU-AI
The virtual machine document is not yet available for distriution.
I (unofficially) gave out a copy or two (e.g. Mike Gordon) but
got into trouble over it from PARC management because it has not
yet been cleared through the lawyer that routinely clears
everything that is written at PARC for outside distribution.
So I'm afraid I can't send you a copy of it until its done
and I have pushed it through the clearance mill.
I am looking around for the code for the compiler and will
let you know soon.
Sorry I forgot about your msg.
J
∂11-Aug-77 0447 RPG New MACLSP
To: MACLSP.DIS[AID,RPG]:;
There is a new MACLSP running at SAIL, which has fancy
high segment capabilities such as
1. High segment stored on a separate file
2. Ability to fasload into the hiseg
3. Ability to create pure list space in hiseg
4. Ability to clobber uuolinks (for debuggin)
5. Ability to save high segments anywhere (and get them back under
all sorts of adverse conditions)
The documentation for the above will be available next week. If you
want to use these features, contact RPG.
∂02-Oct-77 2117 DCO MAIL
To: MACLSP.DIS[AID,RPG]:;
Minor update to MAIL in maclsp. (MAIL <destination> <message>)
evaluates <desination> and <message>, and mails the latter to the former.
e.g (mail 'dco x) will send whatever x is to me. (mail <desination>)
will prompt for the message. (mail) will prompt for both <destination>
and <message>.
∂11-Oct-77 1414 RPG
To: MACLSP.DIS[AID,RPG]:;
Modifications to Step (1 bug fixed; 1 feature added):
1. Use (step) as in the manual. That way (step t) inside a break
should work.
2. New feature: (step-hard ...) which is just like step EXCEPT it
works HARDER! Now, working harder is really true so don't use it
unless you need it. Here's what it does: suppose you have
(defun foo (n) ... (bar ...) ...) and foo is compiled and bar
isn't, and you want to step wherein bar. Well, since eval never sees
the compiled call to bar, ordinary (step (wherein bar)) will lose.
But, if you are stepping-hard, the stepper looks around the FIRST
chance it gets to see if it is inside of BAR; this means it searches
the control stack. If it is in bar it prints
<in BAR>
next-form.
-rpg-
∂21-Oct-77 1333 CGN MACLISP MACRO PACKAGE FOR RECORD STRUCTURES
To: MACLSP.DIS[AID,RPG]:;
I have finished a macro package written by Derek Oppen and myself to
facilite manipulating record structures with named components.
As an example, the call (SHELL MNODE COEF UP LEFT ROW COL) could be
used to "create a data-type MNODE" for sparse matrix nodes which has
five components, by defining access and update macros for the
components and an allocation function for MNODEs. You have your choice
between list-structure or MACLISP hunks for the underlying
representation.
The package is documented in SHELL.LSP[LSP,CGN].
∂02-Nov-77 1616 JP MACLSP meta-D directory feature
To: MACLSP.DIS[AID,RPG]:;
Subsribers of the HELP autodef package:
A new feature has been added to SAIL MACLSP to enable obtaining fast
directory listing using RPG's DIRECT fn. It permits use of >,#, and * as
wildcards. To access the package do when talking to MACLSP
βD <filespec> ;;; note: D not d!
where filespec is of the form filnam.ext[p,pn] and where ext,p,pn and the
syntactic delimiters can be omitted in the obvious cases. * wildcards are
allowed for for filnam and ext. If p or p,pn are omitted, they are
obtained from your current crunit device.
Ext can also be > and #. > obtains the largest numbered version, and # denotes
all numbered versions.
Ex:
*.#[lu,ser ;all files with numeric extension in [lu,ser
*.>[foo, ;the file with largest numeric ext in [foo,
*. ;all files w/o ext in crunit dir
...etc...
NOTE: No wildcards allowed in PPN!
∂06-Nov-77 1503 RPG New features.
To: MACLSP.DIS[AID,RPG]:;
There are two new features in maclisp which are callable
after (help) is performed.
1. (dir) returns a list of (filename <ext>) for your aliased ppn
2. (dir foo) returns a list of files for foo,pn
3. (dir foo bar) returns a list of files for foo,bar
4. (directory 'foo 'bar) returns a list of files for foo,bar
5. (dir /1 /1) returns a list of all known ppn's on the system (takes
a LONG time.
6. (esci-enb) enables [esc]i interrupt for the purpose of interrupting
running jobs. [esc]i<x> is equivalent to <call> reenter <x>,
but only works well when NOT in a read (i.e. will attempt
to complete the read first).
-rpg-
∂24-Nov-76 1518 RPG Debug/Step (SAIL)
To: MACLSP.DIS[AID,RPG]:;
DEBUG now knows about STEP in that while inspecting
stack frames, DEBUG will ignore all frames associated with the
single stepping facility.
∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
To: MACLSP.DIS[AID,RPG]:;
The Step package now UNTRACes any function it has to
single step through. Step will print a message informing the luser
of any UNTRACEs performed.
-rpg-
∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
To: MACLSP.DIS[AID,RPG]:;
The ncomplr now parses file names in winning line mode.
In addition, full decoding of files is now
available. Thus you can say:
FOO.FAS[LO,SER]←FOO.LSR[BLE,TCH](KT)
and all will be well.
∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
To: MACLSP.DIS[AID,RPG]:;
The SAIL Maclisp now sports INPUSH/INPOP, which can be
used to do stack-structured input. Delicately based on the
IOPUSH/IOPOP/MTAPE UUO's at SAIL, they can be used as follows:
***FOO.BAR***
.
.
.
'CIAO
(INPUSH LOSING FLE)
'BACK-AGAIN
.
.
.
***LOSING.FLE***
.
.
.
'HI-THERE
(INPOP)
.
.
.
Then (EREAD FOO BAR DSK (LO SER)) produces:
.
.
.
CIAO
(DSK (LO SER)) ;value of (INPUSH ...)
.
.
.
HI-THERE
T ;due to (INPOP)
BACK-AGAIN
.
.
.
Notice that (INPOP) has to occur in the file: simply letting
(READ) run off the end fails! To remedy this, there is a function
called REQUIRE (given an autoload property by (HELP), which will
(PRINT (EVAL (READ))) everything in the file which is REQUIRE'ed.
It is called as: (REQUIRE LOSING FLE DSK (LO SER)) i.e. it has
the same arguments as UREAD. The NCOMPLR also knows about REQUIRE,
and the proper thing to do is:
(DECLARE (EVAL (READ))
(REQUIRE LOSING FLE DSK (LO SER))
which will work whether the file is being read or compiled.
I would discourage the use of these functions, however,
since they depend on black UUO magic and will possibly disappear
with the onslaught on NEWIO around Armageddon.
∂26-Feb-77 1624 RPG Eread
To: MACLSP.DIS[AID,RPG]:;
Eread, the E-file understanding version of Uread now accepts the
following:
(EREAD <file-name> {<ext> default: no extension}{<device> default: DSK}
(<proj> {<prog> default: prog of dskppn}))
where {} indicates optional args and defaults
∂19-May-77 0118 JP running E from maclsp
To: MACLSP.DIS[AID,RPG]:;
File ET.FAS[MAC,LSP] contains LSUBR ET that swaps to E from MACLSP.
Permissible incantations are
(et '(fil)) ;uses E default extensions in disk dir
(et '(fil ext)) ;disk dir
(et '(fil ext (prj prg)))
(et '(fil (prj prg))) ;default ext
(et) ;runs E on last file edited
Notice that the device is always assumed to be DSK.
Bugs, comments → JP
∂01-Jul-77 2212 DCO MAIL in MACLSP
To: MACLSP.DIS[AID,RPG]:;
MACLSP now accepts mail. If you have the (HELP) option, type
(MAIL) to enter the mail program. You will be prompted to give a destination
list and then the message, both of which must be surrounded by double quotes.
Here is an example of its use:
(MAIL)
Destination? (Any valid MAIL destination list surrounded by "s)
"DCO, RPG%SAIL"
Message? (surrounded by "s)
"Notice that a message may run over any number of lines and may contain
any characters. If you want a double quote in your message, type it twice
as in "". The message now ends."
It is generally faster to send mail using (MAIL) then to use the MAIL
monitor command because (MAIL) does not start up a separate job. The tradeoff
is that the mail is not delivered immediately, but waits until the remind
phantom checks if there is any incoming arpanet mail. This happens roughly
every ten minutes.
∂04-AUG-76 0908 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI) Hiya back
Date: 4 AUG 1976 1208-EDT
From: Guy L. Steele, Jr. (GLS @ MIT-AI)
Subject: Hiya back
To: jra at SU-AI
CC: GLS at MIT-AI
[a] Congratulations on upcoming nuptials.
[b] I have been plowing through chapter six, but
have been very busy lately with MIT projects.
I have not forgotten you, however.
One problem is that I got very frustrated halfway
through the chapter, because of the great profusion
of confusion, and it took a long time to get
up the courage to continue. (Primarily, I was
somewhat annoyed by the radical changes you claimed
were necessary to EVAL to get in shallow binding,
whereas if you had coded the deep binding more
modularly earlier, the changes would be much less drastic.)
Oh well, I'll look forward to seeing new version,
and will passs on my comments on chapter six in any
case when I finish it. Cheers.
- Guy
-------
∂10-SEP-76 1253 FTP:Guy L. Steele, Jr. (GLS @ MIT-AI)
Date: 10 SEP 1976 1552-EST
From: Guy L. Steele, Jr. (GLS @ MIT-AI)
To: jra at SU-AI
CC: GLS at MIT-AI
Ooops, I meant to send off chapter 6 some time ago.
Okay, fair trade. It may take a few days to get all together...
-------
∂03-Dec-76 2304 FTP:GLS at MIT-MC (Guy L. Steele, Jr. )
Date: 4 DEC 1976 0202-EST
Sender: GLS at MIT-MC
From: GLS at MIT-MC (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-MC
Message-ID: <[MIT-MC].17919>
The following mail got routed to some weird destination
at MIT-MC, so I am mailing a copy in case it DIDN't get
to SAIL.
GJS@MIT-AI 12/02/76 20:48:49
To: JOHN at MIT-AI
McCarthy
It's on its way.
∨
GLS@MIT-AI 11/26/76 00:44:20 Re: MONEY, MONEY, MONEY -- also turkey, turkey, turkey
To: GLS at MIT-AI, JOHN at MIT-AI
Allen
much gratitude for the money!
also, recall that "trce, trce, trce" is the best way
to exchange two bits in a pdp-10 ac (see "hakmem"),
and so is appropriate for today.
also great frabjosity today because boston latin
won the latin english game 11-6.
(one day a year i turn into a rabid football fan for
the morning.)
∨
GLS@MIT-AI 11/22/76 12:30:29 Re: lisp
To: JOHN at MIT-AI
CC: GLS at MIT-AI
Allen
One other reference you might want to look at if you haven't
already is:
Fateman, R.J. "Reply to an Editorial." SIGSAM Bulletin 25, pp. 9-11.
I have tried to read the new chapters 2 and 3, but may not have too
much time in immediate future. I'll do what I can.
Presumably what Moses meant was that such details as actually exist
are okay for the public to have. Unfortunately few actual documents
have been produced. That situation should improve in next 6 months.
Meanwhile, I may be able to answer any specific questions
if you need them for the book.
I would be very interested to see Cartwright's work -- I haven't
heard of it.
-- Cheers, Guy
∨
∂04-Dec-76 1321 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
Date: 4 DEC 1976 1620-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].34717>
I assume you meant "hunks". They are essentially a crock,
which I am not entirely proud of, to stave off the address space
crunch in the PDP-10 implementation of MacLISP.
They are essentially short vectors of fixed size; they have
no header as an array does (which occupies 8 words or so).
People generally use them to create small heterogeneous data
structures of more than two components. They take half the space of
a list, since no cdr pointers are needed. They will not
exist on the LISP machine implementation, as the cdr-code
notion yields exactly the same savings, more or less.
Hunks also provide slightly faster access than a list does, but
that consideration is secondary to that of space.
∂27-Dec-76 1247 FTP: host AI xxx
Date: 27 DEC 1976 1547-EST
Sender: gls at MIT-AI
Sent-by: DVM at MIT-AI
Subject: xxx
To: jra at SU-AI
CC: gls at MIT-MC
Message-ID: <[MIT-AI].42656>
No word from McGraw-Hill yet; my thumbs are now getting
quite long. My BS [sic] Thesis is indeed available from
Harvard as a Technical Report. I eagerly await the
publication of the book. Merry Christmas, Happy Chanukah,
Thrilling New Year, usw.
∂06-Nov-77 1159 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) grumble, grumble
Date: 6 NOV 1977 1458-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: grumble, grumble
To: JRA at SU-AI
CC: GLS at MIT-AI
I am told that PASCAL is not as pretty in actuality as people
like to believe; the language definition itself is full of glitches.
(What I am about to say is 1.5-hand information, so double-check
before quoting me.) I am told that the definition explicitly
allows sets to have an implementation-dependent maximum size,
typically 16 or 32. This is evidently so that one can use
single-word boolean instructions to do set operations (e.g. AND
for intersect), and the definers/implementors didn't want to be
bothered with multiple-word operations. Now one of the most
natural sets to deal with, especially when writing the parser
for the compiler, is the character set -- but this set is too
large (at least 64) to represent in most implementations!
I believe that strings also have a maximum length -- but identifiers
do not! This makes it very hard to represent identifiers
as strings in a compiler. I think that in practice the compilers
cheat and limit identifier length.
It may be that in fact there are no dynamically allocatable data
structures in PASCAL at all. You might check out the definition
of EUCLID in SIGPLAN Notices within the past year or two.
All in all, PASCAL is another ALGOL with a couple of good new ideas
(like sets of symbolic constants), but it's not the ultimate answer.
I am busily trying to turn my thesis into a technical report.
I have souped up and cleaned up the compiler a bit more, and will
include it, annotated, as an appendix. Plans are afoot to
experimentally provide lexical scoping on the LISP Machine
and build a RABBIT-like compiler for it. The LISP Machine
otherwise proceeds apace. It has successfully run the Woods LUNAR
program and a good portion of MACSYMA. Tests on LUNAR show that
it is about three times as fast as MacLISP on a KA10, which was
in turn five times faster than in InterLISP. The LISP Machine
has a working compiler and real-time editor. One can use the
editor as the front end to the read-eval-print loop, and the "print"
can go back into the edit buffer in case you want to edit that.
One can have a different editor buffer for each function, and jump
back and forth; there are three commands to exit the editor
(exit, exit and eval, exit and compile). Debugging software is
being developed. Currently undone are bignums, floating point,
interrupts, and the garbage collector. The GC will use Baker's
real-time algorithm (there is never a dead pause, but it is not
asynchronous either; every CONS does a little bit of GC).
The CHAOSNET interface is semi-alive, and the software for it is
being written and tested. The file computer system is being planned.
Eventually there will be a large number of LISp Machines,
all hooked together via CHAOSNET (an Ethernet) to one or more file
computers (which may or may not also be LISP Machines) and the PDP-10s.
The basic LISP Machine idea seems to be working out. The editor is
quite fast, "despite" being written entirely in LISP.
The second prototype is being built; plans call for producing one
production machine a month starting in January.
As for other work, I'm sort of floating about thinking about
writing a Ph.D. thesis proposal. My latest papers were in
SIGPLAN Notices Aug 77 and Proc. ACM 77.
Glad to hear the book is finally about to happen. I can't wait to
see the final product. Have fun out in California, and don't
let the PASCAL types get you down. (You might point out to them
the size of a typical PASCAL compiler compared to a LISP system;
there is a paper in the just-come-out MICRO-10 (SIGMICRO Bulletin)
proceedings about a microcoded LISP machine which makes comparisons
to some other languages -- I think it's by Griss, but there are a
couple of papers of that variety.)
-- Guy
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂04-Mar-79 1020 PEAGRE at MIT-MC (Philip E. Agre) ''Functions ...'' and other Bytery
C00012 ENDMK
C⊗;
∂20-OCT-76 0944 RPG
∂20-OCT-76 0403 JRA LISP
WHAT ARE YOUR FIRST IMPRESSIONS OF MANUSCRIPT? AND HOW FAR ALONG
ARE YOU? IF YOU WANT MORE, THE NEXT CHAPTER IS ALMOST READY.
JOHN
I am pretty much through chapter 2 (reading it fairly
carefully though), and have found some passages somewhat difficult
to understand (difficult in spite of the fact that I understand
what you are trying to get at). In particular, there is the section
on strictness/non-strictness/divergence etc. I have no specific complaints
about it , but I felt uncomfortable reading it the first time. I'm also
not too sure about the real advantage to the t/f vs. T/NIL decision. In some
sense, I view the ambiguity on LISP as one of its features.
I can take the next chapter whenever you are ready. I am planning
to really gung-ho it this weekend and be able to give back the commented
version I am reading.
-rpg-
∂25-OCT-76 1043 RPG
∂25-OCT-76 0358 JRA maclisp listing
the last listing i caught was about 6.5 pounds; that was pre-bibop:1972.
if you can tell me where the file(s) exist, i can list them early in the
morning.
john
ok, the source will appear in 1,rpg by Oct 26. it will be called
lisp.nnn where nnn is something like 232.
I am 3/4 done reading the parts i have and hope to finish tonight.
-rpg-
∂25-OCT-76 1509 RPG MACLISP
WELL, JONL AND I ARE NOW TRYING TO FLUSH THE NON-BIBOP CODE,
SO IT IS NOT IN A GOOD STATE TO LOOK AT.
-RPG-
∂28-Oct-76 2107 RPG BOOK
I have finished the first part of the book and have the following
general comments:
The parts on data structuring seemed to me to be forced. It may
be that I have some residual bigotry on my part, but I felt that it
didn't roll to easily.
On the other hand, I felt that the sections on EVALuation and
spaghetti were among the best I have read in that area (i.e. excellent).
The implementations were quite understandable and the points were well
made.
More specifically, the comparison or analogy between mathematical
definitions and data structuring appeared to be very unnatural, although
I felt that the points made were good.
On spaghetti, my feeling is that it is undoubtedly something for
people who use LISP should know about, but it may not be something that
is ever useful in practice. I have personally never known anyone who has
used it in anything like a production program (except me), and almost none
who have even used it except to see how it works. It seems that there is
always a better way to achieve ones ends than by a general purpose &
inefficient features. Spaghetti invariably saves too much information, tends
to favor lexical variables (especially when you usually want fluid), and forces
laziness on the part of the hacker. For instance, I wrote a hairy pattern
matcher once which required real bactracking in a car/cdr recursion (not a
simple tree search). The matcher often had to bactrack into a control frame
that had been exited. Well, in LISP370 I used spaghetti, and in MACLISP I
explicitly used continuations, which clarified control and was fairly efficient
through the compiler. (the idea was to make the cdr recursion a sub-computation
of the car recursion as opposed to a sister computation). I plan to recode
the LISP370 version soon.
Another point concerns the use of continuations in the book. It
seems that they only appear briefly, as a passing concept between recursion/
subroutine returns and PC control. Well, either continuations should be
presented as a programming skill on its own, or it should be flushed as
a puzzling interlude, or some comment might be derived about its intermediary
position wrt stack control style and Program Counter style.
I am always puzzled about the use of a "LISP Metalanguage" which is
separate from the S-expression notation. I am not questioning the usefullness
of the metalanguage as a theoretical tool of great importance, but the
of it as a pedagogical tool. When I TAed 206 for McCarthy, I saw the
bewilderment it caused when the two notations were introduced in parallel.
A point this "algolishness" seems to obscure is the natural ambiguity inherent
in LISP, namely between the program and the data. Now, I am definitely
not trying to say that it is the ability of LISP to write programs and execute
them which makes i such a nifty language, but that the ability to cons up
certain restricted expressions which can be later applied on a small scale
(that is the handles on the evaluator) that make it a useful language.
A point that you don't seem to make is that LISP is an environment that
the user can sit inside of while his programs suffer trauma, and not a
compiler-based language in which you create your poooooor program, and boot
it into the confusing world of the compiler, tto suffer alone in the cruel
world.
I guess LISP is naturally a hacker's programming language, in that
every nifty hook is available, and you can either hang yourself or not
according to your own abilities.
An important aspect of any comprehensive discussion of LISP is why
it is that such an obscure looking language should be preferred by AI
hackers.
Well, I look forward to the next sections of the book, and will
put the commented first part in your mailbox, if you have one, or mine.
-rpg-
∂10-Nov-76 1351 RPG PROGV Feature
To: MACLSP.DIS[AID,RPG]:;
Here is a little known feature of Maclisp that may be of some
use:
(PROGV <VAR-LIST> <VALUE-LIST> <FORM1> <FORM2> ... <FORMN>)
EVALUATES <FORM1> ... <FORMN> AS A PROGN IN AN ENVIRONMENT
CREATED BY BINDING THE SYMBOLS IN <VAR-LIST> TO THE
RESPECTIVE VALUES IN <VALUE-LIST>. THAT IS, THE FIRST
TWO ARGUMENTS TO PROGV ARE EVALUATED; THE FIRST MUST
PRODUCE A LIST OF SPECIAL VARIABLES, AND THE SECOND
A LIST OF VALUES. THE VARIABLES ARE THEN BOUND TO THE
VALUES. IF TOO FEW VALUES ARE SUPPLIED, THE REST OF
THE VARIABLES ARE BOUND TO NIL. IF TOO MANY VALUES
ARE SUPPLIED, THE EXCESS VALUES ARE IGNORED.
THE BODY OF THE PROGV IS THEN EVALUATED AS A PROGN,
THE VARIABLES UNBOUND TO THEIR OLD VALUES, AND THE
VALUE OF THE LAST FORM IS RETURNED.
EXAMPLE:
(SETQ A 'FOO)
(SETQ B 'BAR)
(PROGV (LIST A B 'B) (LIST B) (LIST A B FOO BAR))
==> (FOO NIL BAR NIL)
∂10-Nov-76 1622 RPG Book
The static structure section is in my box.
I did not find it as well wriiten as the evaluator sections.
In particular the treatment of shallow binding was
misleading/incomplete.
-rpg-
∂11-Dec-78 1724 RPG NEWIO programming tips
To: "@MACLSP.DIS[AID,RPG]" at SU-AI
When compiling a file, if you want to do a require, just say:
(REQUIRE ...)
rather than the older:
(DECLARE (REQUIRE ...))
or whatever. NCOMPLR knows about REQUIRE.
The useful feature EVAL-WHEN can be used to do things in the compiler
environment much like a DECLARE:
(EVAL-WHEN (COMPILE) (DEFUN ZTESCH MACRO ...))
You can also have LOAD and EVAL appear in the options part as well as
the COMPILE. If EVAL and LOAD appear then the form will be EVALed at LOAD time.
(EVAL-WHEN (COMPILE) (DEFUN FOO MACRO (X) 'FOO))
is totally equivalent to
(DECLARE (DEFUN FOO MACRO (X) 'FOO))
and
(EVAL-WHEN (EVAL COMPILE) P1 P2 . . . PN)
is equivalend to
(DECLARE (EVAL (READ)))
(PROGN P1 P2 . . . PN)
finally, one wants a way to cause something to happen during loading
of the compiled code - that is what the LOAD options is.
(EVAL-WHEN (LOAD EVAL) (PRINT 'LOADING-MY-SYSTEM))
∂21-Dec-78 1219 RPG Bug fix in NEWIO
To: "@USERS.DIS[AID,RPG]" at SU-AI
A bug wherein part of the LISP reader believed itself to be
in linemode and part in character has been patched using partial
knowledge. This means that the patch may or may not work, and even
might cause further bugs. Things which could conceivably be effected
are input from non-data-disk/datamedia terminals, programs using
tyipeek, and some kinds of disk IO. Symptoms of further lossage could include
waiting for input when there shouldn't be any, reading too much stuff, etc.
-rpg-
∂22-Dec-78 1630 RPG DEFUN change.
To: "@USERS.DIS[AID,RPG]" at SU-AI
The first atom in a DEFUN is ALWAYS interpreted as the name of the function.
So in (DEFUN FEXPR MACRO ...) FEXPR is the name of the MACRO being defined.
-rpg-
∂09-Jan-79 1542 RPG MacLisp matcher
To: "@USERS.DIS[AID,RPG]" at SU-AI
Here's some changes to %MATCH you matcher fans:
;;;;;;;;;; the matching function ;;;;;;;;;;
;;;
;;; (arg 1) - p - pattern
;;; (arg 2) - d - data
;;; (arg 3) - alist - optional list of variables (* or ?) whose values
;;; are to be retained during the match, much like the
;;; = variables below.
;;; elements of a pattern:
;;; ? - matches anything
;;; * - matches one or more expressions
;;; ?<atom> - like "?", but sets ?<atom> to thing matched
;;; *<atom> - like "*", but sets *<atom> to list of things matched
;;; =<atom> - matched against value of <atom>
;;; (restrict <one of above ?-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil
;;; $r, ⊗r - same as RESTRICT
;;; (restrict <one of above *-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil when given the list
;;; that is being considered for that variable as its argument
;;; (irestrict <one of above *-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil when given each element of the list
;;; that is being considered for that variable as its argument
;;; (done incrementally). So %MATCH will apply these predicates as
;;; it scans the input.
;;; $ir,⊗ir - same as irestrict
;;;
;;; (%match p d <variables to retain>) attempts to match p against d
;;; (%continue-match p d <variables to retain>) attempts to get the next
;;; possible match between p and d (by different *-variable
;;; bindings.
;;*PAGE
∂17-Jan-79 1546 RPG UTIL.>
To: "@USERS.DIS[AID,RPG]" at SU-AI
To speed up compilation (and interpretation), you might try changing your
(require util 1 dsk (aid rpg)) to
(declare (fasload '((dsk (aid rpg)) util fas)))
-rpg-
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂22-DEC-75 0127 FTP:GLS at MIT-AI
Date: 22 DEC 1975 0426-EST
From: GLS at MIT-AI
To: JRA at SU-AI
I would like very much to read a copy of your book.
If you are interested in a poem, might I suggest
TGQ;TREE POEM @ MIT-ML ? Or maybe I will be inspired by reading
the book. I've not done too much about GC lately,
but be it known that I and Sussman have been hacking
with a new LISP-like interpreter, worrying about
implementation and semantics. You might try reading
GJS;SCHDOC MEMO @ MIT-AI (it is in XGP form -- the TJ6 source
is GJS;SCHDOC >).
-------
∂23-DEC-75 1117 FTP:GLS at MIT-AI
Date: 23 DEC 1975 1415-EST
From: GLS at MIT-AI
To: jra at SU-AI
Okay, my address is:
Guy L. Steele Jr.
MIT Project MAC
Room 834
545 Technology Square
Cambridge, Mass 02139
Thanks muchly for opportunity to see wonderful new lisp book.
-- Guy
-------
∂30-DEC-75 0556 FTP:GLS at MIT-ML
Date: 30 DEC 1975 0856-EST
From: GLS at MIT-ML
Subject: LISP MACHINE
To: JRA at SU-AI
WELL, GREENBLATT HAS BEEN OUT OF TOWN FOR A COUPLE OF WEEKS
FOR THE HOLIDAYS, AND BEFORE THAT HE HAS BEEN HACKING THE
CHESS MACHINE MOSTLY. I HAVE SEEN THE LISP MACHINE PERFORM
BYTE DEPOSITS, ETC. (I.E. THE MICROCODE WORKS), BUT I'M
NOT SURE IF THE MAIN MEMORY HAS BEEN HOOKED UP YET. ALSO IT
HAS NO PERIPHERALS RIGHT NOW -- IT HANGS OFF A PDP-11, WHICH
IN TURN IS INTERFACED TO MIT-AI PDP-10.
-------
∂01-JAN-76 0639 FTP:GLS at MIT-ML
Date: 1 JAN 1976 0940-EST
From: GLS at MIT-ML
To: JRA at SU-AI
BOOK ARRIVED YESTERDAY IN FINE CONDITION. I WILL GUARD IT
WITH MY LIFE FROM XEROX MACHINES. IT IS INDEED ALREADY QUITE
BIG -- I WOULD SUGGEST THAT YOU PUT DATA BASES, ETC. IN VOLUME 2.
I'VE NOT READ MORE THAN A FEW PAGES; YOU'LL PROBABLY HEAR MORE
FROM ME AS I PROGRESS. JUST GLANCING THROUGH IT THOUGH, IT LOOKS
LIKE THE BOOK I'VE BEEN WAITING FOR YEARS TO SEE. HAVE A HAPPY
NEW YEAR.
-- GUY
-------
∂19-JAN-76 1220 FTP:GLS at MIT-ML
Date: 19 JAN 1976 1519-EST
From: GLS at MIT-ML
To: JRA at SU-AI
I HAVE BEEN SLOWLY BUT SURELY PLOWING THROUGH THE BOOK.
RIGHT NOW I'VE ABOUT FINISHED CHAPTER 2, BUT MY PACE SHOULD
ACCELERATE NOW THAT MID-JANUARY PWE EXAMS ARE OVER.
I THINK THE APPROACH IS INTERESTING, BUT THERE ARE SOME BUGS.
I'VE LOST YOUR MAILING ADDRESS, SO IF YOU'LL ARPA-MAIL IT
TO ME, I'LL MAIL YOU BACK THE PAGES CHAPTER BY CHAPTER,
WITH TYPOGRAPHICAL CORRECTIONS AND AMUSING COMMENTARY BY
YOURS TRULY.
BY THE WAY, MACRAKIS TELLS ME YOU'LL BE SENDING HIM A COPY?
(GOOD LUCK, HE WILL BITCH EVEN WORSE THAN I WILL.)
-------
∂12-FEB-76 0845 FTP:GLS at MIT-AI
Date: 12 FEB 1976 1143-EST
From: GLS at MIT-AI
To: jra at SU-AI
Be not discouraged. I intend fully to review the entire book.
As I said, I have hope that the last half will be much better.
I'm sorry if I seemed harsh in my letter. I will be quiet busy
for the next couple of weeks, but I think I can certainly mail
you reviewed chapters at the rate of one every three or four weeks
at worst. Would that be sufficiently fast for your purposes?
-------
∂12-FEB-76 0902 FTP:GLS at MIT-AI
Date: 12 FEB 1976 1200-EST
From: GLS at MIT-AI
To: jra at SU-AI
Well, now that I have a better idea of your audience,
I can do a better job of reviewing, I guess.
Maybe what mislead me was the title: "The Anatomy of LISP"
looks like it means a book about LISP. Maybe you want
something like "Computer Science: a LISP Approach",
except that that sounds like a tired cliche. "The Anatomy
of LISP" is a great title -- it's just that it's not
precisely what the book is about, in some sense.
But maybe I am picking nits.
I suppose that m-expressions are okay. I still say they are
hard to read. Maybe if you had a better font, and pretyy-printed them
better. I hope the printers have a good font. The major problems are
that the semicolons are italic, and would look better if vertaical;
and that the square brackets don't have enough space between them,
so they're hard to count.
While you may not want to use "top", I think it is still true that
one shouldn't confuse errors with non-termination. I don't see
how coalesced sums can possibly hurt you. Another way is to use
"super-bottom" and "super-top"; i.e., every domain has its own
bottom and top, and there is a special bottom below all other
bottoms, and similarly tops. But it is very confusing
to say that bottom means "undefined", and later to say "[43 -> x; y]
isn't 'bottom' -- it's *really* undefined".
-------
∂03-Mar-77 1603 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) Knight displays
Date: 3 MAR 1977 1904-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
Subject: Knight displays
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].70877>
Well, a Knight display terminal consists of a TV monitor and
a separate keyboard (made by Microswitch). The TV gives something
like 450 by 380 raster (i forget exact figures); using a 6x12
character matrix, this gives 96 chars wide and 37 or so lines.
The TV screen is repetitively refreshed on a bit basis from
a memory.
There are far more terminals than can be used at once - they are cheap
enough to have one in every office, naturally. There are
14 "video buffers" of 16K 16-bit words apiece (room for
expansion to 16 buffers). There is a crossbar (the video switch)
which connects bit sources to bit sinks (16x32). Currently
the only sources are the video buffers, and sinks include all
the terminals and a Tektronix copier.
The video buffers hang off a unibus interface on a PDP-11.
A register controls which one is accessible to the unibus
(the PDP-11 also has 12K of normal memory). The PDP-11 in turn
hangs off the MIT-AI pdp-10 to pdp-11 inteface, which makes
PDP-11 memory addressable from the PDP-10. In this way
a user program, after making a number of system calls, can
write directly into the bits of the TV screen:
the user memory refeence is mapped by the paging box to a magic
address in high memory (location 2,,xxxxxx); the 10-11 interface
maps it to the correct PDP-11; the unibus interface maps it
to the correct TV buffer; and voila!
The unibus interface for the buffers has an ALU inside of it
which is sometimes useful; it can do an IORM faster for you
than the PDP-10 can.
The kayboards are similar to Stanford keyboards,
but I think have a few more keys. They generate 15 bits
(64 code-generating keys @ 6 bits, shift lock, and left/right
each of ctrl/meta/top/shift). The PDP-11 immediately folds this to 12
bits (top,shift lock, shift, meta, ctrl, and 7 bits of ascii)
and passes it to the PDP-10. User programs can read them
in 12-bit or 7-bit mode. User programs that read 12 bits
conventionally fold them down to 9 bits (meta, ctrl, ascii)
though they don't have to.
that answerthe question? if not, tk@ai himself can probably helpp more.
-- Guy
∂01-Feb-78 1057 FTP:GLS at MIT-AI (Guy L. Steele, Jr.) last message
Date: 1 FEB 1978 1356-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: last message
To: JRA at SU-AI
CC: GLS at MIT-AI, (BUG LISPM) at MIT-AI
please, please. i'd like to know how to get information about
lisp machine, perhaps including lisp source.
john
Sorry. The best thing to do is contact the LISP Machine Group
(BUG-LISPM @ MIT-AI). The LISP Machine code lives
on various directories such as LISPM, LISPM1, and LMDOC
at MIT-AI, but you will probably have a hard time wading around
in it without guidance from wizards.
∂25-Jan-79 1821 GLS LISP etc.
To: JRA at SU-AI
CC: GLS at SU-AI
Unfortunately I will be immensely busy during the next month or two,
and don't eally have the time to write an article for BYTE in the
near future, much as I would like to. An AI memo should come out
fairly soon concerning the LISP chip, and a shorter paper is appearing
in the proceedings of the Caltech conference on VLSI which I just now
got back from. I'll be sure to send you a copy. I got a copy of your
book from McGraw-Hill, and it looks pretty good. Thanks for the
warm acknowledgement in the preface. Are you still at HP, or what
are you doing?
-- Guy
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂27-Feb-78 1706 HPM more video
1. the xgp-to-gray sacle algorithm ( i know you told me once, but
(blush, blush) i forgot.
2. given the gray scale channels, how much smoothing does the
video synthesizer do.
*******
imagine a page of XGP output. It is 8 1/2 by 11 inches and has 200
dots per linear inch in each direction, each dot being black or white.
Call a black dot a 1 and a white spot a 0. The page is then an array
of 2200 rows and 1700 columns of bits.
Each data disc channel is conceptually organized into 480 rows and 512
columns of bits. There are 32 of these channels altogether, all producing
bits simultaneously. Normally they are used to operate 32 different tv
screens, each a 480 by 512 by one bit display. Eight of these channels go
to a digital to analog converter. This D/A is thus provided with eight
bits for each of the 480x512 points on a TV screen. It takes these
8 bits and translates them to one of 2↑8 grey level values. Thus the
output of the D/A is a tv image with 480x512 samples, each one of 2↑8
shades of grey. The data-disc:D/A converter is called the video
synthesizer. There is no additional smoothing except perhaps that
caused by the limited frequency response of the video amplifiers
anlong the way to your TV screen, and by the finite spot size of
the electron beam in your CRT.
The XGP dot array is more than three times as wide the data disc
array, and more than four times as tall. Also, the TV screens are
wider than they are tall, making them just about right for displaying
a half page of XGP output. A half page is still over 3 times as wide
and 2 times as tall as the DD array. By throwing away some of the
(hopefully) blank border on the page, the ratios are made exactly
3 and 2. So now imagine that each DD dot must somehow represent
a little 3 by 2 subarray of the XGP array. If we sum up the number
of 1's in each of these subarrays, we get numbers from 0 to 6.
If 0 represents white and 6 represents black, with the numbers
in between representing proportional shades of grey, we can display
the resulting pattern on the video synthesizer. It looks like
a blurred version of the XGP page. That's half density XGPSYN.
Full density turns the page on its side and compresses the
page length by a factor of 4 (instead of 2) and the width by
3, as for half density. Double density does 4 lengthwise and
6 sideways (giving numbers from 0 through 24).
The simple summing over subrectangles is a filtering. Other
more complicated filtering algorithms, that involve shading some
adjacent dots, might give even better results [CACM V20 #11 799:805].
*******
3. where, oh where, might i find the video synthesizer details
and even perhaps the xgp synthesizer listings?
*******
The source for XGPSYN is XGPSYN.SAI[PIX,HPM], though I don't think
it will be too helpful.
*******
these and other questions can only be answered by YOU.
besides, the gratitude of the huddled masses, I'd even autograph
a copy of my forthcoming (and outgoing) LISP book.
*******
wow!
*******
i await pregnantly,
john
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂29-Oct-76 1101 RPG GRIND
To: MACLSP.DIS[AID,RPG]:;
The MACLISP grinder now understands E-files. Grinding an E format
file will cause the directory to be flushed.
-rpg-
∂29-Oct-76 1824 RPG BIBOPIZATION
To: MACLSP.DIS[AID,RPG]:;
MACLSP is now fully BIBOPized and SAIL housebroken.
MACLSP, NCOMPLR, & SCHEME all run under BIBOP; MACLSP IO routines
understand E-format files. This includes NCOMPLR and the GRINDer.
Don't forget to use EREAD in place of UREAD for all normal disk IO.
(This is the routine that understands E.)
-rpg-
∂01-Nov-76 2201 RPG BIBOP
To: MACLSP.DIS[AID,RPG]:;
Don't forget, R MACLSP invokes the latest BIBOP version
of MACLISP.
-rpg-
∂14-Dec-76 2221 RPG Printing windows/SAIL
To: MACLSP.DIS[AID,RPG]:;
One can now print the window surrounding a CE by
saying "W" to the Editor. If the windowsize is 2, then the
2 tokens preceeding the CE, the CE, and the 2 tokens following
the CE are printed (a token is an expression or a parenthesis).
The windowsize is set by (WINDOW n).
∂09-Jun-77 1415 RPG sewer OLDIO
To: MACLSP.DIS[AID,RPG]:;
At SAIL Maclisp has been modified as follows: ordinary disk file
IO now uses 6 buffers in the input (output) buffer rings and fasload reads
1400(8) words at a time from disk in dump mode while fasloading. Since the
bottleneck at SAIL is the disk right now these changes will greatly
improve the performance of Maclisp AND the rest of the lusers on the
SAIL machine. However, there are a few things to watch out for:
1. the correctness of Require in this new scheme has not been proven.
2. BPS will need to be increased for fasload. Essentially fasload
uses array space for its dump mode buffering. So, the increased size
(200 to 1400 (8)) means that BPS should be about 1200(8) [640.] words larger
than before. You ought to go through your *.ini files and make this
update or face "no core -- array" errors.
-rpg-
∂10-Jun-77 1145 JP E - MACLSP - E
To: MACLSP.DIS[AID,RPG]:;
ET.FAS[MAC,LSP] has been modified so ⊗XRUNning from E returns you
to the calling MACLSP image. LSUBR ET now returns nil. Comments → JP
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂23-FEB-76 1503 FTP: host HARV
***** FTP mail from [7101,422] (HOWARD)
JOHN:
I FINISHED TRANSFERING THE FILES. YOU WILL FIND (I HOPE) THE
FOLLOWING ON YOUR DIRECTORIES:
BUILDL.DOC LMAN.DOC EDIT1.DOC EDIT2.DOC MI.DOC GUTS.DOC
AUXFNS SVLISP HACK TRACE EDIT BT
SPARM.M11 LGLOB.M11 MACRO.M11 DSTUF.M11 ATDAT.M11
E SUBR.M11 SUBRCOM.M11 EARLY.M11 SYSS.M11 GCOL.M11 NOW.M11 FP.M11
SYSEND.M11 PROB7.M11 PROB8.M11 PROB8.ORI PRO
CTABLE.M11 PROBEND FILLER.M11 NOROOM.M11
MI.TEC
SHRLISP
THE USER'S MANUAL IS LMAN.DOC... BUILDLISP.DOC TELLS HOW TO MAKE A LISP
FROM SCRATCH. GUTS.DOC DESCRIBS THE INTERNALS OF THE LISP SYSTEM.
THE EDIT FILES ARE FOR THE IN-CORE EDITOR THAT NO-ONE
USES SINCE WE'VE PUT IN (TECO 'FILE) AND (TECF(FUNC1 ... FUCN)).
THE SECOND GROUP IS THE LIBRARY. AUXFNS IS PRE-LOADED, WITH HACK AND SVLISP. THE OTHER'S ARE LOADED BY THE USER WHEN HE WISHES.
THE THIRD GROUP IS THE SOURCE FOR LISP. THE FILE MI.TEC IS A OFTEN USED
MACRO FOR LIST STRUCTURE INSERTION . THE FILE SHRLISP IS TEHE UNIX
CCL FILE TO MAKE A LISP.
I HOPE THAT THIS IS WHAT YOU NEED. IF THERE IS ANY OTHER PART
OF UNIX LISP THAT YOU WANT TO GET AHOLD OF, LET ME KNOW.
FORREST HOWARD
(PS PLEASE LET ME KNOW IF YOU GIVE A COPY OF LISP TO ANYONE ELSE.
YOU'RE WELCOME TO DO SO, BUT I'D LIKE TO KEEP TRACK OF WHERE
IT LIVES.)
FORREST W. HOWARD JR.
CENTER FOR RESEARCH IN COMPUTING TECHNOLOGY
AIKEN COMPUTATION LAB
HARVARD UNIVERSIT
CAMBRIDGE, MA. 02138
GOOD LUCK
FORREST
∂09-MAR-76 1311 FTP:HOWARD at HARV-10 LISP/BOOK
Date: 9 Mar 1976 1610-Edt
From: HOWARD at HARV-10
Subject: LISP/BOOK
To: JRA at SU-AI
JOHN:
SORRY I TOOK SO LONG TO GET BACK TO YOU. FIRST YOUR COMMENTS:
THE FRMPTR WAS A CELL I ADDED AT THE REQUEST OF AN UNDERGRAD
(JOHN BURRUS) THAT HE FELT NECESSARY TO IMPLEMENT SPAGETTI
STACKS. HOWEVER, THAT WAS LAST SPRING, AND JOHN HAS GONE FORTH
TO MAJOR IN ENGLISH. SPAGETTI STACKS ARE SOMETHING I'M PLANNING
EVENTUALLY (MAYBE LATE SUMMER).
XFER LISP IS THE PDP-10- UNIX ENVIRONMENT TRANSFER PROJECT, WHICH
I'M DOING TO JUSTIFY MY EXISTANCE THESE DAYS. WE'RE PLANNING
ON TRANSFERING A COMPLETE ENVIRONMENT (DATA AND CONTROL) TO THE
10 TO CONTINUE RUNNING WHEN WE'RE BLOCKED ON THE 1.( AT
THE MOMENT "BLOCKED" MEANS NO CORE, BUT WE EVENTUALLY HOPE TO DEVISE
ALGORITHIMS FOR THE MONITOR TO "TELL" LISP IT'S BLOCKED).
THE OBLIST SWITCHING IS SOMETHING I DID LAST SPRING WHEN TAKING
A COURSE AT MIT UNDER RON RIVEST. SEE THE CURRENT ACM FOR THE
SPECIFICS.. BASICALLY, IT A "MOVE TOWARDS THE FRONT" ALGORITHIM
TO SPEED UP OBLIST SEARCHING.
INDEED THIS IS CLOSE TO PRENNER'S LISP-- WHEN I ORIGINALLY WROTE AS AN UUNDERGRAD,
WE WE CONVERTING APPL. MATH [[0 (MACHINE LANGUAGE) TO UNIX FROM A 10, AND
WERE TRYING TO MAKE THE COURSES (AND PROBLEM SETS AND LISP)
AS IDENTICAL AS POSSIBLE.
I WILL BE INTERESTED IN SEEING THE BOOK... SOUNDS LIKE IT SHOULD BE GOOD
READING
TQAKE CARE
FORREST
I SHOULD MENTION THAT OTHER GOODIES ARE AVAILABLE FROM THE SAME
ADDRESS, INCLUDING TECO, RT-11 BASIC, A DDT, SOURCES FOR THE
ASSEMBLER AND LINKER, AND A PROGRAMMING LANGUAGE CALLED "PPL",
STANDING FOR POLYMORPHIC PROGRAMMING LANGUAGE. THESE ARE ALL ON
A BASIS SIMILAR TO LISP. ECL FOR THE 11 IS ALSO COMMING SOON.
OTHER GOODIEES ARE AVAILABLE FROM BERKELY (INGRESS, A DATA BASE
SYSTEM), COMMERCIAL UNION LEASING CO, NEW YORK (FORTRAN 4-PLUS ) (YECH!!)
AND THE NAVAL POST-GRADUATE SCHOOL (A DEBUGER AND OTHER STUFF). BELL IS
RUMORED TO BE WORKING ON ALGOL-68 COMPILERS.
3) YOUR BOOK WAS READ FOR THE SECOND TIME LAST SATURDAY. TYPO'S
I NOTICED WERE "ABRECIATION" FOR ABREVIATION (ABOUT PAGE 30)
(YOU MIGHT HAVE MEANT THIS) AND SEVERAL PLACES TOWARDS THE
BACK OF THE BOOK WHERE THE PABE NUMBERING WAS SCREWED UP
IN ITS TYPEOUT.
I RESPECT TO FORMAT, I FOUND THE BOOK FAIRLY INTERESTING.
THE SECTIONS THAT I MOST WANTED TO SEE (FUNARGS, SPAGETTI,
QUANATATIVE TRADEOFFS BETWEEN SM AND DEEP-BINDING) WERE ALL
"MORE ON ...." SECTIONS. THE REST OF IT SEEMS WELL THOUGHT OUT,
AND WELL PRESENTED.
I'M NOT SURE IF I AGREE WITH THE ADVOIDANCE OF NIL AND T,
AS WELL AS THE CONCEPT OF FIRST, SECOND, ...; IT SEEMS TO ME
THAT JUST AS THE PROGRAMMER IN ASSEMBLER KNOWS THAT A 0 IS
FALSE OR HALT, AND A 1 IS TRUE OR AN INSTRUCTION, THE LISP
USER SHOULD BE AWARE OF THE
DUALITY OF VARIOUS OBJECTS. THE NOTION OF FIRST&CO. WOULD SEEM
TO HELP CONFUSE THE HOPEFULLY CLEAR RELATIONSHIP BETWEEN LISTS
AND DOTTED-PAIRS.
THE OVERALL ORGINIZATION IS GOOD. THE IDEA OF PRESENTING LISP
MATHEMATICALLY FIRST, FOLLOWED BY THE ISSUES AND THEN A COMPILE
TO SEE HOW TO DO THINGS SEEMS REASONABLE.
I PROMISE TO READ A THIRD TIME, AND MAKE FULL COMENTS THEN.
ONE MORE THING, I'M LEAVING FOR PARIS ON JUNE 1, SO TRY
TO GET CORROSPENDENCE TO ME BY THEN. I PLAN TO LOG IN HERE ABOUT
ONCE EVERY 2 WEEKS (FROM THE LONDON TIP), SO POST THAT MAIL AND
YOU'LL EVENTUALLY GET AN ANSWER. AFTER OCTOBER I'LL BE WORKING FOR
COMMERCIAL UNION LEASING CO, 645 MADISON, NYC, 10022 (I THINK)
SO SNAIL-MAIL CAN GET ME THERE (I HOPE TO ALSO KEEP THIS ACCOUNT).
FORREST
∂24-MAY-76 1141 FTP: host HARV
***** FTP mail from [7101,422] (HOWARD)
JOHN:
A QUICK REPLY TO YOUR LETTER:
1) UNIX RUNS ON ANY 11 WITH SEGMENTATION (MEMORY MANAGEMANT UNIT) AND
EXTENDED INSTRUCTION SET (IF A 11/40 (THIS MEANS SOB, MUL, DIV)).
ONE BLOCK TYPE DEVICE IS REQUIRED (DECTAPE, RK DISK, RP DISK, ETC).
IT IS EXTREMLY FLEXIBLE IN THE CONFIGURATIONS THAT IT ACCEPTS; I
HAVE RUN UNICIES WITH ONE DECTAPE AS A "ROOT FILESYSTEM" AND SWAP
DEVICE, AND THE OTHER DECTAPE AS A "REMOVABLE FILESYSTEM".
THE BIGGER AND FASTER THE DISKS/TAPES THE BETTER, BUT ALMOST ANYTHING
WILL DO.
UNIX SUPPORTS ALMOST ANY PERHIPERAL MADE BY DEC, AND QUITE AFEW FOREIGN
PERHIPERALS (VOICE SYNTHESISERS, PHOTOTYPESETTERS, GOULD PRINTERS, ETC.).
OH YES -- YOU NEED MEMORY TO MANAGE. ABOUT 64 K WDS IS THE MINIMUM THAT I
WOULD CONSIDER, ALTHOUGH I'VE SEEN SMALLER.
2) RUMOR HAS IT THAT BELL HAS UNICIES TO RUN ON THE LSI-11 AND 11/20 OR
11/05. YOU'LL HAVE TO TALK TO THEM TO FIND OUT.
3) UNIX MAY BE CONVERABLE TO A DEC MONITOR. THE WAY DEC ORGANIZES THEIR
STACK-PROT
STACK/PROGRAM/DATA IS DIFFERENT THAN UNIX (DEC LIKES PROG HIGH IN CORE,
DATA IMMEDIATLY BELOW, STACK BELOW THAT. UNIX LIKES PROG LOW, DATA FOLLOWING AND
STACK STARTING AT -2 GROWING TOWARDS 0.) MAPING THE SYSTEM CALLS WILL BE FAIRLY
ESASY, AS I'VE TRIED TO (AT LEAST INITIALLY) TO LEAVE ALL THE
SYSTEM DEPENDENT STUFF IN ONE MODULE (THIS EFFORT HAS DETERIORATED OVER TIME).
AS A LAST RESORT, AL SPECTOR AT HARVARD WROTE A UNIX "MONITOR" THAT FITS
INTO A BARE MACHINE AND CAN BE USED TO HELP OUT WITH STUFF. AL WILL BE A
1-G AND STANFORD NEXT YEAR.
4) THE BIGGEST LOSS ABOUT USING UNIX LISP UNDER A DEC MONITOR OR 11-40 IS THE
LOSS OF I&D SPACE SEPERATION CAPABILITY. UNDER AN 11-45 OR EQUIVILANT, THE
USER HAS ABOUT 27.5 K OF DATA (NOT COUNING STACK) TO DO THINGS WITH.
THIS DROPS TO ABOUT 22K UNDER AN 11/40 OR NON-I&D MACHINE.
(P.S. ANOTHER ADVANTAGE OF I&D IS THE "FREENESS" OF NEW SUBRS OR FSUBRS.
THAT IS THE CODE FOR NEW SUBRS JUST POPS INTO I-SPACE, AND DSPACE REMAINS THE
SAME SIZE, WITH THE LANGUAGE BEING MORE POWERFUL AND/OR CONVENIENT.)
MORE ON THE BOOK TO COME. I GOTTA CODE RIGHT NOW, HOWEVER (I HEAR THAT
PLANE DRAWING CLOSE).
FORREST
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂02-May-78 1245 MG ML (LCF metelanguage)
To play with ML do "R ELCF" then when you get the LISP prompt
* do "(TML)" (u.c.) and then respond with <return> to both "THEORY?"
and "DRAFT?".e.g. simulated interaction:
.r elcf
*(TML)
LCF version 5 issued 27-oct-77
(with simultaneous substitution and new simplification)
THEORY?*
DRAFT?*
* .......
.........
..........etc.eg
.
.
.*letrec map fn l = null l => [] | (fn (hd l)).map fn (tl l));;..
----------------------------------------------------------
The ML prompt should be "#" but to do this needs (DE PROMPT (N) ...?...)
--eg see PROMPT[LCF,FWH] for the Edinburgh hack.
See yah....Mike
∂02-May-78 1258 MG erratum
"fn(hd l).map fn (tl l)" is more correct - ihad an extra bracket before
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂19-Jul-77 1436 JP
To: MACLSP.DIS[AID,RPG]:;
SAIL MACLSP interprocess communication
A preliminary version of a MACLISP interjob communication facility is
available to those of you lusers subscribing to the (help) autoload
facility. These functions permit arbitrary creation, deletion,
synchronization and intercommunication of MACLISP processes. For more
information read FASFRK.JP[LIB,LSP].
-j
∂06-Apr-78 1232 RPG New Maclsp
To: MACLSP.DIS[AID,RPG]:
Warning! LISP 1525 has been installed, the first new assembly
since September 1977. At the next opportunity you should re-make any
systems based on Maclisp as well as reassemble any LAP code which
does file IO. Also, you should READ LSPARC (the first 3-4 pages) to
learn of the changes in this version. Good luck.
-rpg-
∂07-Apr-78 1018 RPG *rset
To: MACLSP.DIS[AID,RPG]:
Remember, the default for *rset in MacLisp 1525 is t, not nil as
in all previous versions. Also, LISP.INI files, if present, are automatically
loaded.
-rpg-
∂07-Apr-78 1624 RPG Lisp 1525
To: MACLSP.DIS[AID,RPG]:
Compiled hunk code appears to lose in MacLisp 1525.
If this will effect you, use sys:maclsp.old.
-rpg-
∂07-Apr-78 1809 RPG Hunk bug in MacLisp 1525
To: MACLSP.DIS[AID,RPG]:
Re-compile all files which use hunks.
-rpg-
∂13-Jan-79 1005 Feigenbaum at SUMEX-AIM hp310
Date: 13 Jan 1979 1005-PST
From: Feigenbaum at SUMEX-AIM
Subject: hp310
To: jra at SU-AI
John, never heard of it. Sounds like someone put a lisp on an hp-300,
doesn't it? Anyway, if you find out more, let me know.
Ed
-------
∂01-MAR-76 1749 FTP:FEIGENBAUM at SUMEX-AIM book reviewers
Date: 1 MAR 1976 1749-PST
From: FEIGENBAUM at SUMEX-AIM
Subject: book reviewers
To: jra at SU-AI
everything is set. it is time for us to choose reviewers. Let us
talk by telephone and settle on something (someone;or plural).
please call. office or home (493-5618).
regardss, ed
-------
∂05-FEB-76 0941 FTP:FEIGENBAUM at SUMEX-AIM book review
Date: 5 FEB 1976 0940-PST
From: FEIGENBAUM at SUMEX-AIM
Subject: book review
To: jra at SU-AI
john, i am discussing the review situation this morning with
the new editor of the McGraw-Hill Computer Science Series, and
will get back to you today or tomorrow with news.
Regards, ed
-------
∂29-DEC-75 1251 FTP:ENGELMORE at SUMEX-AIM
Date: 29 DEC 1975 1243-PST
From: ENGELMORE at SUMEX-AIM
Subject: book
To: jra at SU-AI
john, sorry that i have not got back to you. i got the book and will
begin the editorial process shortly. things have been chaotic over the
holidats.....ed
-------
∂08-AUG-75 0927 network site SUMEX
Date: 8 AUG 1975 0927-PDT
From: FEIGENBAUM at SUMEX-AIM
Subject: book contract
To: jra at SU-AI
i talked with the cognizant mc-graw hill people about your contract.
your contract got engtangled in the question, "what market does it
fit into?" i had tried to answer that question for them in various
ways previously, but apparently there was a conflict between your
statement to them about this subject and mine...or somee other similar
confusion. in any eevent they will generate the promised contact soon
(for "contact" read "contract").i apologize for the confusion and the
delay.
your communications with others varies between the rational-academic-
colleagular mode and the angry-emotional mode. i have observed the
latter bexx but never experienced it personally until your last
message. that first experience was also hopefully the last.please
use only the former mode with me.
sincerely, ed feigenbaum
-------
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂05-Dec-78 0833 RG at MIT-AI (Richard Greenblatt)
Date: 5 DEC 1978 1135-EST
From: RG at MIT-AI (Richard Greenblatt)
To: JRA at SU-AI
NO RESPONSE INTENDED.. SOUNDS LIKE SORT OF AN INTERESTING
IDEA, BUT I SORT OF THINK IT WOULD MUDDY THE WATER TOO MUCH RIGHT
NOW. IN OTHER WORDS, I THINK WE SHOULD PROBABLY LET THAT SLEEPING
DOG LIE FOR A YEAR OR SO, IF POSSIBLE.
∂21-Jan-79 2044 BAKER at MIT-AI (Henry G. Baker, Jr.) Lisp article
Date: 21 JAN 1979 2339-EST
From: BAKER at MIT-AI (Henry G. Baker, Jr.)
Subject: Lisp article
To: CARL at MIT-AI, jra at SU-AI
CC: BAKER at MIT-AI
The article would be a review of the list representation issues and
how they interact with the garbage collector.
I would hope that the advantages of garbage collection would be included
in another article; if not, I will include some of them.
I will not present a particular scheme for a particular micro-computer.
(The idea of making a usable lisp for a 64kbyte machine is ridiculous).
However, I will review several schemes for encoding list structure to
take up less space.
One issue of particular interest to me: how much money ($'s) is available
for these articles. The last time I talked to Carl Helmers, the rates
were terribly low.
Henry Baker
∂20-Jan-79 1445 Boyer at SRI-KL (Bob Boyer) Your book reviewed
Date: 20 Jan 1979 1445-PST
From: Boyer at SRI-KL (Bob Boyer)
Subject: Your book reviewed
To: JRA at SU-AI
I am not suprised that your book got a nasty review. The most recent
experience that I have had with the CR book review method were the
two reviews of Dijkstra's book "A Discipline of Programming." The
book received two rave reviews. I think it's a lousy book, and I
was delighted when Floyd completely panned the book in the American
Scientist.
I recently replied to a publisher who was inquiring about whether to
have a certain book written that I would us your book in a class
on the subject, that you had produced an excellent book, and that
it would be difficult for anyone to produce a better one. It would
certainly take them years.
-------
∂20-Jan-79 1754 RZ at MIT-MC (Richard E. Zippel)
Date: 20 JAN 1979 2056-EST
From: RZ at MIT-MC (Richard E. Zippel)
Sent-by: RLB at MIT-MC
To: JRA at SU-AI, carl at MIT-AI
CC: RWK at MIT-MC, RLB at MIT-MC, HIC at MIT-MC, RZ at MIT-MC
This is to inform you that some subset of us will be submitting a
paper for the August issue of BYTE. The title will probably be
something like "LIL - A Lisp Implementation Language". We will
present a Lisp based compiler for implementing system software.
With the language (compiler and perhaps interpreter) embedded in
a Lisp-like environment, the user will have access to the Lisp
debugging tools. We feel that the ability to manipulate programs
via macros coded in Lisp will speed the code writing phase. This
language should be usable on micro-processors without difficulty.
∂22-Jan-79 0637 RLB,RWK,RZ,HIC at MIT-MC BYTE paper on LIL
Date: 22 JAN 1979 0939-EST
From: RLB,RWK,RZ,HIC at MIT-MC
Sent-by: RLB at MIT-MC
Subject: BYTE paper on LIL
To: JRA at SU-AI
CC: RLB at MIT-MC, RWK at MIT-MC, RZ at MIT-MC, HIC at MIT-MC
We need some idea about how long this should be - of course, it might
depend on how winning the outline is ...
∂04-Feb-79 1226 RWK at MIT-MC (Robert W. Kerns)
Date: 4 FEB 1979 1526-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: jra at SU-AI
CC: RZ at MIT-MC, RLB at MIT-MC, HIC at MIT-MC, RWK at MIT-MC
CC: CARL at MIT-MC
Here is a preliminary outline of our proposed LIL paper. It would help us
a lot if you could give us some idea of how much space we can expect for
this paper, and how many diagrams it would be good to include, and of course
the deadlines.
Preliminary LIL paper outline
1. WHY MESS WITH LIL?
a. Motivation - what is an implementation language? Why do we need one?
b. LIL is not X for X in {LISP, BLISS, C, Pascal, PL/I, assembler, etc.}
c. Post parse-time macros (as opposed to textual substitution pre-parse-time
macros)
i. Used for user-extentions to the control structure of the language
ii. Used to extend the semantics of the language
iii. Used to extend the data structures which the language can handle.
d. Debugging aids via interpretation in LISP.
e. Stand alone debugging aids.
f. Extra control structures not found in other languages.
2. WHAT IS LIL?
a. Overture - What LIL offers, generally - functions, variables, pointers,
special forms (control-sturcture contstructs)
b. Syntax - what there is of it
i. lexical scan is easy, (), prefix characters ".' - symbols/number
ii. parse is trivial, explicit list notation
iii. all built into LISP's READ function.
c. Basic semantics
i. Function calling
ii. Variables
iii. . and ' (pointer-follower and address prefix)
d. Special forms (case, select, do, cond, and, or, etc.)
e. Macros - written in LISP, not LIL!
i. LISP is a good language for manipulating LIL code. (Or other code)
ii. Full interpreter available in the compiler.
f. Micros down to machine code level.
i. Give hands-on access to special capabilities of the host machine
ii. Enforce transportability; all machine-dependent code is in the form
of micros; these can be re-coded for new machine, the machine
dependencies have been isolated.
iii. Full user-control of compilation
g. User-defined optimizations.
3. COMPILER
a. Why write compiler in LISP
b. Optimization
4. INTERPRETER
a. Incremental debugging
b. Single step debugging, at source-code level, not machine-level.
c. Why you want both a compiler and an interpreter
5. COMPARE & CONTRAST LIL WITH OTHER IMPLEMENTATION LANGUAGES
a. Detail here that couldn't be included in section 1.
b. Sample program expressed in several such languages
(Perhaps do the core of a BASIC interpreter)
c. BLISS as LIL; show how LISP makes language manipulations easy
6. EXAMPLE AND DESCRIPTION OF WHAT WE'VE IMPLEMENTED
a. Not a lot yet, but we're trying.
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂21-Jan-79 0944 PHW at MIT-AI (Patrick H. Winston)
Date: 21 JAN 1979 1243-EST
From: PHW at MIT-AI (Patrick H. Winston)
To: JRA at SU-AI
I DONT KNOW ABOUT HP THING. ASK ONE OF THE LISP
PEOPLE, SAY RG, TK, OR H.
I HAVE RECEIVED A COPY OF YOUR BOOK AND I HAVE SCANNED IT.
I AM MUCH IMPRESSED. PEOPLE I TRUST THAT HAVE READ IT
SAY ITS GREAT. CONGRATULATIONS ON A FINE JOB.
PATRICK
∂21-Jan-79 1528 BAK at MIT-MC (William A. Kornfeld) BYTE article
Date: 21 JAN 1979 1829-EST
From: BAK at MIT-MC (William A. Kornfeld)
Subject: BYTE article
To: jra at SU-AI
CC: BAK at MIT-MC
What I had in mind for the article is the following:
Show how easy it is to use list structure to represent structured objects
in a database. For example, in a database of student records:
(Courses (Smith John) (Fall 1977) (Calculus←1 Physics Philosophy))
(Courses (Jones Mary) (Spring 1978) (Category←Theory General←Relativity))
(Student-at (Smith John) MIT)
(Student-at (Jones Mary) Boston←University)
and show how easy it is to write a pattern matcher to allow you to allow
you to get records for John Smith for 1977 by using the pattern:
(Courses (Smith John) (? 1977) ?)
This could then lead into a discussion of deriving facts that are not
explicitly stored, such as with the database:
(Mary mother←of Sam)
(Sam father←of Alice)
Who are the grandmothers of Alice? and this becomes code something like:
(when (?man father←of Alice)
(when (?woman mother←of ~man)
(assert (grandmother Alice ~woman)))
This will show how patterned data objects can be manipulated. After this
should follow a discussion of pattern directed invocation of procedures.
Rather than the function call (GRANDMOTHERS Alice) which has to know all
the ways of deducing this from facts stored in the database, there is
a demons that have as pattern:
(when (find←all (grandmother =person))
<...look for a father of person and then his mother ...>)
(when (find←all (grandmother =person))
<...look for a mother of person and then her mother ...>)
(when (find←all (grandmother =person))
<...look for an assertion of the form (grandchild ~person =the-grandmother)
and return the-grandmother>)
and then broadcast (find←all (grandmother Alice)) to invoke all these procedures
simultaneously.
These would get across the basic concepts. Other topics that could be developed
to a greater or lesser detail would be: [1] the kinds of AI programs that have
been written using these kinds of systems and topics such as antecedent versus
consequent reasoning. [2] The idea of "contexts" or having many
databases that form a tree with layering.[3] How these assertions can be coded
much more efficiently in a discrimination net so that access time becomes
nearly independent of the size of the database.
These examples were thought up in the space of a few minutes and more
interesting ones should be easy to find. I think that the hairy macro
characters could be done away with by using mixed upper/lower case or font
changes to make it more readable.
Questions I have:
1. How long should it be (and which of the above auxiliary topics do you think
should be developed the most)?
2. How much familiarity with Lisp should I assume on the part of the reader.
Should I avoid the use of Lisp code? Can I talk freely about recursion
when describing the pattern matcher? How about such topics as quoting or
environments (such as would be returned by the pattern matcher) or avoid
these issues totally?
I will be available to devote time to this starting in about a week. It should
hopefully not take too long to write.
Concerning my master's thesis, right now I'm summarizing it in a paper for IJCAI
and I'll send you a copy of this as soon as it is completed.
Hope to get your comments on this soon.
--Bill
∂03-Feb-79 1116 BAK at MIT-MC (William A. Kornfeld)
Date: 3 FEB 1979 1416-EST
From: BAK at MIT-MC (William A. Kornfeld)
To: jra at SU-AI
Hi. Are you still interested in the article on pattern directed invocation?
I have time now to devote to it. I would like to know when it has to be
done by and approximately how long it should be.
--Bill